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FAULT TOLERANT TELEPHONY CONTROL 

BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates generally to a technique for providing telephony 
control fault tolerance in a communications system, and more specifically, to such a 
technique that provides agent workstation telephony control fault tolerance. 

Brief Description of Related Prior Art 

Systems for managing and routing calls through public and/or private communi- 
cations networks are known in the art. Conventional automatic call distribution (ACD) 
systems route calls to agents in telemarketing and service inquiry centers, and provide 
limited real-time call management and reporting capabilities. A typical ACD system will 
monitor the status of the agent and, when an incoming call is received, selects the agent 
to handle a particular service request. Reporting and performance data from the agents 
are also generated by the ACD. 

One particular type of scheme for distributing calls to agents is disclosed in 
Frauenthal et al., U.S. Patent No. 4,737,983. According to Frauenthal et al., data repre- 
senting the present call congestion of each of the ACD systems is accumulated in a data 
base. Using the data in the data base, the percentage of calls made to the ACD systems, 
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as a group, is determined. The information is then used to generate call routing informa- 
tion. When a new call is made to the central office, the routing information is queried to 
determine which of the ACD systems is to receive the call, so as to balance the call traffic 
load across the ACD systems. 

5 Another call management and distribution scheme is provided in Gechter et al., 

U.S. Patent No. 5,036,535. This patent discloses a system for automatically distributing 
telephone calls placed over a network to one of a plurality of agent stations connected to 
the network via service interfaces, and providing status messages to the network. Gech- 
ter et al.'s disclosed system includes means for receiving the agent status messages and 

10 call arrival messages from the network, which means are connected via a network service 
interface to the network. Routing means responsive to the receiving means is provided 
for generating a routing signal provided to the network to connect the incoming call to an 
agent station through the network. In the system disclosed in Gechter et al., when an in- 
coming call is made to the call router, it decides which agent station should receive the 

15 call, establishes a call with that agent station, and then transfers the original call onto the 
second call to connect the incoming caller directly to the agent station and then drops out 
of the connection (See, Gechter et al., column 11, lines 45-51). 

Other prior art call management, routing, and distribution techniques are disclosed 
in Andrews et al., U.S. Patent No. 5,873,130, which is assigned to the Assignee of the 
20 subject application. This patent discloses a communications system and method for 
automatically making telephone routing decisions with global authority based upon in- 
formation gathered in real time from the entire communications system and global opti- 
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mization criteria. The entirety of the disclosure of the Andrews et al. patent is incorpo- 
rated herein by reference. 

Conventional communications systems of the type disclosed in the aforesaid An- 
drews et al. patent typically comprise one or more ACD systems connected to each other 
5 via at least one public switched telephone network (PSTN). The ACD systems and the 
PSTN may be controlled by a central controller so as to route calls to and from agents 
(and/or caller services, such as interactive voice response units) associated with such 
systems, and callers external thereto, through the ACD systems and PSTN. 

Unfortunately, conventional ACD systems typically are complex telecommunica- 
10 tions devices that are costly to acquire and maintain. Thus, the use of conventional ACD 
systems in a communications system inherently increases the cost and complexity of im- 
plementing, using, and maintaining the communications system. 

Accordingly, in an effort to reduce or eliminate the need to use such conventional 
ACD systems, it has been proposed to provide non-ACD agent systems that exhibit 

15 ACD-like functionality and operation in a communication system. In such non-ACD 
agent systems, a plurality of agent computer-telephony integration (CTI) workstation 
computer nodes may be provisioned with controllable telephony devices. These teleph- 
ony devices may be directly connected to the PSTN, or alternatively, may be connected 
to the PSTN via a PBX to enable certain call operations (e.g., agent conference and con- 

20 sultative call operations, and call transfer operations) to be implemented in the non-ACD 
agent system. Further alternatively, the telephony devices may be configured to establish 
and receive Internet Protocol (IP) telephony calls, using voice-over-IP technology, over 
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an IP network. This may offer cost advantages over traditional Plain Old Telephone 
Service (POTS) telephony, as in contradistinction to POTS telephony, both voice and 
data may be carried over a single IP network connection; the use of IP telephony has also 
become more attractive with the widespread and increasing availability of broadband ac- 
5 cess. The agent workstations, their telephony devices, and the PBX may be controlled by 
a telephony control mechanism external to the workstations. 

More specifically, the control mechanism may comprise at least one telephony 
control process residing and executing in at least one computer node linked to the work- 
stations via computer network links. This control process controls other telephony con- 
10 trol processes (e.g., server processes based upon the telephony application interface 
(TAPI) protocol of Microsoft Corporation of Redmond, Washington) resident in the 
workstations. The TAPI server processes in the workstations control the respective te- 
lephony devices in the workstations so as to facilitate implementation of desired call op- 
erations. 

is As is known to those skilled in the art, according to the TAPI protocol, a single 

respective client process can control only a single respective TAPI server process. Thus, 
in order to implement the above-described non-ACD agent system, in each agent work- 
station, a respective TAPI-based client process may be provided to act as a respective in- 
terface that permits the establishment of a respective control communication path or link 

20 between the telephony control process in the external telephony control mechanism and 
the respective TAPI server process resident in the workstation. By providing these re- 
spective TAPI-based client processes, it becomes possible for the telephony control proc- 
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ess in the external telephony control mechanism to control the multiple TAPI server pro- 
cesses in the workstations, and thereby, to control the telephony operations of worksta- 
tions' telephony devices. 

There are a number of ways in which a control communication link between the 
5 telephony control process in the external telephony control mechanism and a TAPI-based 
client process may fail (i.e., experience a failure condition in its operation, such as, ceas- 
ing to permit exchange of telephony commands and responses thereto). Examples of 
events that may cause such a control communication link to fail include the failure of the 
client process, the failure of the external telephony control process or mechanism, and/or 
10 the failure of a network communication link between the workstation and the mechanism. 
A failure of the client process or the external telephony control process can be caused by, 
e.g., the experiencing by such processes of an untrapped exception or a deadlock in exe- 
cution. A failure of a network link or the external telephony control mechanism can be 
caused by, e.g., a fatal electrical or mechanical failure of the network link or mechanism. 

15 Unfortunately, if the control communication path established by a TAPI-based 

client process in an agent workstation fails, then it becomes impossible to control the te- 
lephony operations of the workstation's telephony device; this can make it impossible for 
the agent associated with the workstation to properly receive, establish, and process calls 
using the workstation. 
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SUMMARY OF THE INVENTION 

Accordingly, a telephony control fault tolerance technique is provided that over- 
comes the aforesaid and other disadvantages and drawbacks of the prior art. More spe- 
cifically, in one embodiment of the technique of the present invention, a CTI agent work- 
5 station node may be provided with a primary telephony control communication path or 
link between a primary telephony control mechanism external to the workstation and a 
TAPI process resident in the workstation's memory. The TAPI process may be for use in 
controlling a telephony device in the workstation. In the event of failure of the primary 
path, a secondary telephony control communication path or link may be established and 
10 activated between the TAPI process and a secondary telephony control mechanism com- 
prised in or local to the workstation. 

The primary communication path may be established, at least in part, via a second 
process resident in the workstation's memory. The second communication path may be 
established, at least in part, via a third process resident in the workstation's memory. 

15 The TAPI process may be a TAPI server process. The second process may be 

TAPI-based client process configured to act as an interface that permits the external pri- 
mary telephony control mechanism to control multiple TAPI server processes (e.g., com- 
prised and executing in respective agent CTI workstations). 

The primary telephony control mechanism may be linked to the agent CTI work- 
20 stations via computer network connections or links. The failure of the primary control 
path in a workstation may result from one or more of the following: a failure of the sec- 
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ond process, a failure of the network connection linking the primary control mechanism 
to the workstation, and a failure of the telephony control mechanism. 

Advantageously, by establishing in an agent workstation, in the event of failure of 
the primary communication link, a secondary communication link between the first proc- 
ess and the secondary telephony control mechanism, control of the first process may be 
maintained (e.g., using the secondary control mechanism) even after such failure. This 
makes it possible to control the telephony operations of the telephony device in the work- 
station, even after such failure. 

It will be appreciated by those skilled in the art that although the following De- 
tailed Description will proceed with reference being made to illustrative embodiments 
and methods of use, the present invention is not intended to be limited to these embodi- 
ments and methods of use. Rather, the present invention is of broad scope and is in- 
tended to be defined as only set forth in the accompanying claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other features and advantages of the present invention will become apparent as 
the following Detailed Description proceeds, and upon reference to the Drawings, 
wherein like numerals depict like parts, and wherein: 

Figure 1 is a functional block diagram of one embodiment of a communications 
system wherein the present invention may be practiced to advantage. 



PATENT 
112025-0437C1 
Seq. No. 8360 

Figure 2 is a functional block diagram of the primary central controller of the 
system of Figure 1. 

Figure 3 is a functional block diagram of one type of agent system that may be 
used in the system of Figure 1. 

Figure 4 is a functional block diagram of an administrative workstation used in 
the system of Figure 1. 

Figure 5 is a schematic block diagram illustrating data structures in the database 
shown in Figure 4. 

Figure 6 is a functional block diagram of another type of agent system that may 
be used in the system of Figure 1. 

Figure 7 is a functional block diagram illustrating computer program processes 
that may be resident in the memory in an agent CTI computer workstation node in accor- 
dance with one embodiment of the present invention. 

It will be appreciated by those skilled in the art that although the following De- 
tailed Description will proceed with reference being made to illustrative embodiments 
and methods of use, the present invention is not intended to be limited to these embodi- 
ments and methods of use. Rather, the present invention is of broad scope and is in- 
tended to be defined as only set forth in the accompanying claims. 

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 

Figure 1 is an architectural-level block diagram illustrating functional components 

of a communications system 10 wherein the present invention may be practiced. System 
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10 includes a plurality of agent systems 24, 26, 28 connected to a primary central con- 
troller 30 and a plurality of public telephone and/or long distance carrier networks (e.g., 
British Telecom, Energis, France Telecom, Cable and Wireless, MCI, Sprint, AT&T) 12, 
14, 16. Calling devices 18, 20, 22 place calls to called devices (i.e., agent systems 24, 26, 
28) via public networks 12, 14, 16. As will be explained more fully below, primary cen- 
tral controller 30 generates command messages for controlling routing and distribution of 
calls through the long distance carriers to and from the agent systems, and through the 
agent systems themselves to and from individual workgroups, agents and/or caller serv- 
ices, based upon requested service messages (e.g., telephone numbers and/or other infor- 
mation and messages supplied from the calling devices and public networks, and/or call 
management request messages from the called devices), status messages (i.e., availability 
of resources for use by callers, loading of system resources, etc.) supplied by the agent 
systems, and user-generated call routing control scripts) stored in controller 30. Admini- 
stration workstation 32 permits user access and control of the system 10 by, for example, 
permitting generation and modification of system configuration data, call routing scripts, 
etc. stored in controller 30. Monitoring and diagnostic mechanism 3 1 monitors the vari- 
ous elements of the system (i.e., the agent systems 24, 26, 28, administration means 32, 
etc.) to determine whether these elements are functioning properly. If a malfunction is 
detected, that fact is signaled to the central controller 30, so that it can undertake appro- 
priate action to correct and/or eliminate the malfunction and/or any resulting problems to 
the system 10 from the malfunction. 

Although not shown in the Figures, each of the conventional long distance carri- 
ers 12, 14, 16 includes a long distance control network (e.g., AT&T's Signaling System 7 
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(SS7) control network, MCI's TCP/IP-based control network, Sprint's X.25-based con- 
trol network and/or foreign telecommunication's CCITT SS7-based control network) and 
local exchange carriers. The long distance control networks control routing of calls 
through the long distance network serviced by the exchange carriers. When a long dis- 
tance call request is initially received by the exchange carrier, from a calling device (e.g., 
a caller at a calling device dials a long distance telephone number) it forwards the call 
request to the long distance network, which routes the call to its intended destination. In 
system 10, when the long distance control network receives a request for long distance 
connection to one of the agents in the agent systems' workgroups or caller services, the 
long distance control network forwards the long distance routing request to the central 
controller 30. As will be described more flxlly below, central controller 30 then processes 
the request and controls the system 10 to route the call to a destination in accordance with 
call routing control scripts executed by the controller 30. The system 10 accomplishes 
call routing by, inter alia, translating the routing request message into a route response or 
command message that addresses the desired destination. System 10 also supports rout- 
ing of calls across local exchange carriers and international PTT's by utilizing substan- 
tially the same call control and distribution techniques discussed above. 

As is known to those skilled in the art, call destinations are commonly termed 
"labels." A "label" may be or specify, e.g., a particular destination telephone number. 

Figure 2 is a schematic block diagram illustrating functional components of the 
central controller 30. Controller 30 includes interfaces 33 for receiving status and re- 
quested service messages, and for supplying command messages generating by the con- 
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troller 30 to the public networks and the agent systems. Interfaces 33 include long dis- 
tance carrier network interface controllers (NTCs) 38, 40, 42 that interface the controller 
30 to the public networks 12, 14, 16, respectively. Each of the NICs 38, 40, 42 is appro- 
priately constructed to permit transmission of command messages to and receipt of re- 
quested service and other messages from the respective network to which it is connected. 
For example, if NIC 42 is connected to an AT&T network, then it is appropriately con- 
structed to permit transfer of command and requested service messages between the con- 
troller 30 and the SS7 network; additionally, the NIC 42 may be constructed to receive 
and process from the SS7 network confirmation messages that confirm that command 
messages provided to the SS7 are proper for the SS7 network and have or are being acted 
upon by the SS7 network. Other types of carriers must also be similarly accommodated 
by appropriately constructing the other NICs 40, 38 to permit exchange of such messages 
between these networks and the controller 30. 

Interfaces 33 also include agent interfaces 34 for interfacing the controller 30 to 
the agent systems 24, 26, 28. Interfaces 34 include agent system interfaces 46 connected 
to a conventional wide area network interface 44 which connects the controller 30 to the 
interfaces 34 so as to permit transmission of status and other messages from the agent 
systems to the routing engine 48, and to permit transmission of command and other mes- 
sages to the agent systems 24, 26, 28. It should be understood that the particular types of 
interfaces 46 used will depend upon the particular constructions of the agent systems, the 
wide area network (not shown) that connects the controller to the agent systems, and the 
controller itself. Interface 44 may be adapted for use with a conventional TCP/IP 

(Transmission Control Protocol/Internet Protocol) network (not shown, which connects 
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the controller to the agent systems), although alternatively, interface 44 may be con- 
structed for use with networks that use other network protocols. 

Control signal generator 36 is connected to the interfaces 33, monitoring mecha- 
nism 31, and administrative workstation 32. Control signal generator 36 comprises rout- 
ing engine 48, database logger/retrieving engine 50, database manager 52, and database 
54. Routing engine 48 determines how to route calls in the system 10 (i.e., through the 
public networks to the agent systems, and in the agent systems themselves), and transmits 
this routing information (e.g., in the form of appropriate command messages) that address 
the desired end-termination (e.g., an agent station or CTI workstation in a workgroup or a 
caller service in the system) to interfaces 33, 34 for transmission to the agent systems and 
long distance control networks, respectively. In order to determine how to route calls in 
the system, routing engine 48 may take into consideration, among other things, real-time 
requested service messages supplied to it by the interfaces 33, system configuration data 
202 (see Figure 5) and historical (i.e., previously stored) requested service data derived 
from requested service messages and status messages 204 retrieved by logger/retriever 50 
at the command of the routing engine 48 from the system's historical database (compris- 
ing database manager 52 and storage mechanism 54), real-time status messages from the 
agent systems supplied to it from the interfaces 34, information from the monitoring 
mechanism 3 1 concerning what components (if any) of the system are currently unavail- 
able because they are malfunctioning or inoperative, and routing optimization criteria 
and/or rules and commands in the form of call routing control scripts 200 generated by 
the administration workstation and stored in database 54. Routine engine 48 uses this 

data to determine the manner in which to route calls in the system. After making its deci- 
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sion on how best to route a particular call, generating appropriate command messages to 
implement this decision, and transmitting the command messages to the interfaces 33 and 
34, routing engine 48 instructs logging engine 50 to store the real-time information pre- 
sented above in the database 54 for use in determining how to route later calls. Logging 
engine 50 in turn, commands database manager 52 to store this information in database 
54. 

Figure 3 is a functional block diagram of one type of agent system that may be 
used in the system of Figure 1. Agent system 26 comprises an interface 72 for interfac- 
ing the agent system's local controller/router 70 to the controller's wide area network in- 
terface 44, so as to permit transfer of command and other messages from controller 30 to 
local controller 70 and status and other messages from the local controller 70 to controller 
30. In response to command and other messages received by local router 70 from con- 
troller 30, local router 70 issues commands to the ACD/IVR, or PBX system causing 
public network interfaces (not shown) in the ACD, PBX or IVR to connect and discon- 
nect calls received thereat from the public networks to and from appropriate caller serv- 
ices (e.g. interactive voice response system 74) or individual agents (e.g. connected to 
private branch exchange (PBX) 56 or ACD 60). It should be noted that the particular 
type and number of caller services and agent workgroups shown in Figure 3 are merely 
for illustrative purposes and may vary. Local router 70 issues commands via the conven- 
tional local network 58 to the caller service or individual agent system in the workgroup 
to which the call is connected, as to how the individual agent or caller service is to dis- 
tribute or process the call. For example, depending upon the command messages trans- 
mitted by the controller 30 to controller 70, controller 70 may instruct the call to be for- 
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warded directly to the interactive voice response system 74 which is connected as an an- 
swering resource to ACD 60, and instruct the interactive voice response system to store 
information from the call for later retrieval and transmission to a workstation (not shown) 
connected to the PBX 56, or to connect the call to the ACD 60 and instruct the ACD to 
forward the call to one of its workgroups 62, 64, 66. Of course, it will be appreciated that 
if appropriately modified, the network interfaces may be comprised within the public 
networks or may comprise separate, stand-alone interfaces distinct from the agent sys- 
tems. Likewise, if the PBX, IVR, and/or ACD are appropriately modified so as to include 
other of the various functional components of the agents (e.g. router 70), they may be 
eliminated, or comprised as separate functional components from the agent system. Lo- 
cal controller 70 also queries the individual agents and caller services for status informa- 
tion (e.g. whether they are active or busy, what resources are available for use by callers, 
etc.), gathers this status information via the local network 58, and transmits this informa- 
tion to the central controller 30 via interface 72 for use in the central controller's routing 
decisions. 

Agent system 26 may also comprise local administration workstation 73 for per- 
mitting user control of the local router 70, and remote administration workstation 71 for 
permitting remote control of central controller 30. Both administration workstations 73, 
71 are of similar construction to administration workstation 32. Local administration 
workstation 73 may be limited in its ability to control local router 70 (i.e., only to control 
matters not being controlled by central controller 30). Likewise, remote administration 
workstation 71 may be limited in its authority over system 10 such that administration 

workstation 32 may override commands issued by administration workstation 71. 
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Figure 4 is a functional block diagram of administration workstation 32. Work- 
station 32 may comprise a user input/output interface 78 connected to central controller 
interface 76. User interface 78 may comprise a graphical user interface for permitting a 
human user 80 to generate, edit, and store call control routing scripts 200, system con- 
figuration data 202, etc. in the database 54 of the central controller 30. The database in- 
terface 76 is adapted to change the user's graphically input data into a form usable by the 
central controller in the central controller's database 54. Administration workstation 32 
comprises a user-accessible database 75 for storing real-time information and configura- 
tion information and for permitting such information to be communicated to a human 
user via the user interface 78. Also, administration workstation 32 permits a user to 
monitor various system activities and current system information, such as, call routing, 
system configuration, etc. 

Figure 6 is a functional block diagram of another type of agent system 24 that 
may be used in system 10. In contrast to the agent system 26 whose construction is illus- 
trated in Figure 3, the agent system 24 does not include an ACD system. Instead, as will 
be described more fully below, agent system 24 comprises, among other things, a plural- 
ity of computer program processes executing in a plurality of computer nodes that oper- 
ate in a such a way as to permit agent system 24 to exhibit certain ACD-like functionali- 
ties. As is shown in Figure 6, non-ACD agent system 24 comprises a wide area network 
interface 300 for interfacing the local controller/router 302 of the agent system 24 to the 
wide area network interface 44 of the central controller 30, so as to permit transfer of 
command and other messages from controller 30 to local controller 302 and status and 

other messages (including CTI event status messages) from the local controller 302 to 
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controller 30. In response to command and other messages received by local controller 
302 from the central controller 30, local controller 302 issues commands and data to the 
CTI controller 304, and also issues commands to the agent CTI workstations 306, 308. 

More specifically, each workstation 306, 308 comprises respective telephony- 
related hardware and executing software processes (e.g., based upon TAPI protocol) that 
permit the workstations 306, 308 to receive and process incoming calls from, and to es- 
tablish outgoing calls to, the networks 12, 14, 16. By controlling the hardware and soft- 
ware processes, controller 302 is able to control the telephony operations of the worksta- 
tions 306, 308, including answering and termination of incoming calls, and establishment 
and termination of outgoing calls. The telephony hardware may also include conven- 
tional mechanisms (e.g., comprising respective agent telephone headsets and mouth- 
pieces) for permitting the agents 314, 316 to communicate with the callers involved in 
such incoming and outgoing calls, and conventional mechanisms for providing physical 
connectivity to the networks 12, 14, 16 (e.g., comprising respective Music Telecom 1 x 
1™ telephony device cards 310, 312). Alternatively, if the workstations receive and es- 
tablish IP telephony calls, the network(s) 12, 14, 16 may comprise one or more IP net- 
works (which may comprise or be comprised in the same data network that includes CTI 
controller 304) via which such calls may be received or established. In this alternative 
arrangement, the devices 310, 312 may comprise Windows 2000™ h323 client and/or 
Section Initialed Protocol (SIP) TAPI service provider processes/devices for facilitating 
establishment of voice-over-IP telephony calls over such EP networks. 

The commands and data issued by the controller 302 to the controller 304 may 

control the provision of, among other things, agent status and call processing-related in- 
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formation from the controller 304 to application processes (not shown) executing in the 
individual workstations 306, 308. For example, based upon commands and data that it 
receives from the local controller 302, CTI controller 304 may gather information related 
to the processing of calls by, and the current status of, the workstations 306, 308 and 
agent system 24, and may provide that information to these application processes, and to 
the controller 302. Such information may include, e.g., whether a particular agent work- 
station is busy (i.e., actively "off-hook" and connected to a call), waiting to receive a call, 
connected to an as yet unanswered call, available to receive a call, etc. These application 
programs may then use computer/user interfaces 31 1, 309 to display this information in a 
form that is understandable by human agents 314, 316, respectively, so as to permit the 
agents 3 14, 3 16 to be able to monitor the processing of calls by their respective worksta- 
tions 306, 308 and by the system 24. These application program processes and interfaces 
3 1 1, 309 also provide a mechanism by which agents 3 14, 316 may request the establish- 
ment of outbound calls from the agent system 24 via one or more of the networks 12, 14, 
16, using an embodiment of the technique of the present invention, and may request 
changes in respective statuses of the workstations 306, 308 (e.g., the agents 314, 316 may 
request the termination of particular calls received or initiated by the workstations). 

Controller 304 may also provide, based upon commands and data received from 
the controller 302, call context information concerning particular calls received by the 
workstations. The contents of such call context information may vary, and for example, 
may include ANI-related information, digits entered or dialed by the caller placing the 
call, customer account number and/or other information related to previous business 

transactions made by the caller, and/or other call-identification-related information. The 
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call context information may be initially gathered by, and forwarded to, the controller 
302 by the controller 30. Agent system 28 may have the same construction and operation 
as agent system 24. 

The above-presented functional components (with the exception of public net- 
works 12, 14, and 16 and PBX 56 and ACD system 60 of agent system 26) of system 10 
may be embodied as, or comprise one or more distributed computer program processes 
executing in a plurality of computer nodes; each of these nodes may include computer- 
readable memory for storing software programs, algorithms, and data structures associ- 
ated with, and for carrying out, the inventive techniques, and related and other techniques 
and methods described herein as being carried out by or implemented in system 10. In 
addition, each of these nodes may further include a processor (e.g., an Intel 80x86 proc- 
essor) for executing these software programs and algorithms, and for manipulating the 
stored data structures, to enable the nodes to carry out these methods and techniques in 
system 10. Additionally, the nodes may be provisioned with such networking hardware 
and software (e.g., including computer networking and telephonic communications hard- 
ware and software) as is needed to enable performance of the stated functionality. 

It should be noted that the functional components of the system 10 may vary de- 
pending upon particular functional and operational requirements. For example, the ex- 
isting components of system 10 may be modified to incorporate the functionality of, or 
the system 10 may be modified to include, fault-tolerance-related functional components 
(e.g., a redundant central controller), components related to processing of Internet calls, 
and/or call-queuing-related components described in the aforesaid Andrews et al. patent 
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(i.e., U.S. Patent No. 5,873,130). Accordingly, it should be appreciated that the present 
invention may be practiced in systems other than system 10 (e.g., in systems having dif- 
ferent and/or additional functional components like those described in the aforesaid An- 
drews et al. patent, and other communications systems). 

Figure 7 illustrates a respective set 403 of telephony control computer program 
processes, according to one embodiment of the present invention, that may be resident 
and executing in the respective computer-readable memory (e.g., comprising random ac- 
cess and/or read-only memory) 400 in an agent workstation (e.g., workstation 306) of the 
agent system 24. Each of the other CTI agent workstations in agent systems of the type 
shown in Figure 6 may comprise respective sets of processes that are substantially similar 
to processes 403. As shown in Figure 7, processes 403 include low-level telephony de- 
vice driver and related processes 416 that directly control the operation of the telephony 
device 310 in workstation 306, and receive from the device 310 information related to the 
status and operation of the device 310. Processes 416 are controlled by a TAPI server 
process 414, which process 414 receives from the processes 416 messages indicative of 
the information received by the processes 416 from the device 3 10. 

As stated previously, controller 302 provides telephony control commands to the 
workstation 306 that control the telephony operations of the device 310. More specifi- 
cally, in accordance with this embodiment of the present invention, agent workstation 
telephony control processes (not shown) resident and executing in computer-readable 
memory in controller 302 provide, via a computer network communications link 303 
(e.g., comprising a wide or local area TCP/IP-based network link), telephony control 

command messages to the network interface processes 410 in memory 400 of workstation 
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306. These command messages are converted by processes 410 into a form suitable for 
receipt and processing by a TAPI client process 408. 

TAPI client process 408 and TAPI server process 414 may communicate with 
each other using conventional functions/protocols provided by TAPI Dynamic Link Li- 
brary (DLL) program code provided by the Microsoft Corporation of Redmond, Wash- 
ington. That is, process 408 may provide telephony command messages to process 414, 
and process 414 may provide to process 408 messages indicative of the information re- 
ceived by the processes 416 from the device 3 10, by invoking/utilizing the conventional 
functions/protocols provided by TAPI DLL program code. The command messages from 
the process 408 may reflect or be indicative of command messages received by the proc- 
esses 410 from the controller 302. Messages received by the process 408 from the server 
process 414 may be converted by processes 410 into form suitable for transmission to the 
controller 302 via the link 303, and being so converted, may be transmitted by the proc- 
esses 410 via the link 303 to the controller 302. 

In essence, TAPI client process 408 acts as an interface between the telephony 
control processes in controller 302 and the TAPI server process 414 that permits the es- 
tablishment of a primary control communication path or link between the telephony con- 
trol processes in controller 302 and the process 414 that permits the telephony control 
processes in controller 302 both to control the telephony operations of the device 310 and 
to receive information related to the status and operation of the device 310. The proc- 
esses 408 in the workstations 306, 308 are constructed such that, by providing in each 
agent workstation a respective TAPI process 408, the telephony control processes in 

controller 302 may separately address and control each of the server processes 414 in the 

20 



PATENT 
112025-0437C1 
Seq. No. 8360 

respective workstations, and separately associate telephony status messages from such 
processes 414 with the respective workstations in which the processes 414 reside. 

In accordance with this embodiment of the present invention, a secondary TAPI 
interface client process 406 is resident and executing in memory 400. A monitoring pro- 
cess 422 is also resident and executing in the memory 400. Process 422 periodically 
polls (via provision of appropriate polling messages to the primary interface process 408) 
the process 408 to determine whether process 408 is functioning properly. If the process 
408 does not properly respond to such polling messages from the process 406, the proc- 
ess 422 determines therefrom that the process 408 has failed. Failure of the process 408 
inherently causes the link 418 to fail, and may be caused directly by failure of the process 
408. A failure of the process 408 may be caused by, e.g., the experiencing by the process 
408 of an untrapped exception or a deadlock in execution. When process 422 determines 
that process 408 has failed, process 422 may terminate and restart the process 408, and 
may provide appropriate messages to the process 406 to cause secondary link 420 to be- 
come active. 

Alternatively, the link 418 may fail as a result of failure of link 303 and/or CTI 
network link 305. A failure of link 303 may be caused by, e.g., a fatal electrical or me- 
chanical failure of the network link 303 itself or controller 302. A failure of the CTI net- 
work link 305 may be caused by e.g., a fatal electrical or mechanical failure of the net- 
work link 305, itself or controller 304. Assuming that process 408 is functioning nor- 
mally, process 408 may determine that link 303 or link 305 has failed if, e.g., process 408 
repeatedly fails to receive responses to messages sent by process 408 via links 303, 305. 

When process 408 determines that either link 303 or link 305 has failed, it may close 
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primary link 418, and then cause process 406 to active the secondary link 420 (e.g., via 
invoking an appropriate TAPI "HneHandofT procedure). Additionally, controller 302 
periodically polls the process 408 to determine whether the process 408 is active (i.e., has 
not failed); if the controller 302 determines that the process 408 has failed, and the link 
303 has not failed, the controller 302 may cause local Active-X-based telephony control 
processes 404 resident and executing in memory 400 to cause the process 406 to activate 
secondary link 420. Also, if the controller 304 determines that the process has become 
unresponsive, and the link 305 had not failed, the controller 304 may transmit appropriate 
messages via interface processes 402 that command the local control processes 404 to 
cause the secondary link 420 to become active. Alternatively, the controllers 302, 304 
may command the local Active-X-based telephony control processes 404 to provide the 
agent with an indication that process 408 has failed. Based upon this information, the 
agent 3 14 may command the processes 404 to cause the process 406 to make active the 
link 420. 

During normal conditions, the process 406 receives copies of the messages sent 
by the process 414 to the process 408, but does not act upon any of these received mes- 
sages. The agent 314 may provide commands to the processes 404 via the interface 3 1 1 
that control the telephony operations of the device 3 10 so as to permit the agent 3 14 to 
continue, e.g., to properly receive, establish, and process calls using the workstation 306, 
despite the failure of the link 418. More specifically, when the processes 404 receive 
such commands from the agent 314, the processes 404 may command the process 406 to 
command the server process 414 to implement the commands from the agent 3 14. In re- 
sponse to such commands from the processes 404, the process 406 may issue appropriate 
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commands to the server process 414 that, when executed by the process 414, cause the 
processes 416 to cause the device 3 10 to implement the telephony operations commanded 
by the agent 3 14. The process 406 exchanges messages with the process 414 using the 
TAPI DLL program code in a manner similar to that used by the process 408 (i.e., in the 
absence of a failure of the link 418). 

Thus, after the process 408 has failed, the processes 404 may use process 406 to 
establish a secondary control communications link 420 between the local telephony con- 
trol processes 404 and the server process 414 that permits the processes 404 to function 
as a secondary mechanism (in contradistinction to the primary mechanism provided by 
the controller 302) for controlling the telephony operations of the device 3 10 of worksta- 
tion 306. However, unless and until the process 408 has failed, the link 420 does not be- 
come active for use by the control processes 404. 

Further details of the construction and operation of system 10 (and particularly, of 
the non-ACD agent system 24) are disclosed in co-pending U.S. Patent Appln. (Serial 
No. yet to be assigned, Atty. Docket No. 1 12025-426) entitled "Call Management Im- 
plemented Using Call Routing Engine," and co-pending U.S. Patent Appln. (Serial No. 
yet to be assigned, Atty. Docket No. 1 12025-427) entitled, "Associating Call Appearance 
With Data Associated With Call." Each of said co-pending applications is being filed 
concurrently with the subject application and is assigned to the Assignee of the subject 
application. Each of said co-pending applications is also hereby incorporated by refer- 
ence, in its entirety, into the subject application. 

It should be understood that above-described embodiments are being presented 

herein as examples and that many variations and alternatives thereof are possible. Ac- 
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cordingly, the present invention should be viewed broadly as being defined only as set 
forth in the hereinafter appended claims. 

What is claimed is: 
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